Review notes from recent call:

1. needs rebase for new nav groups
2. src/app/Shared/Services/api.utils.ts needs an update for the WebSocket notification category handling

Also, some tests would be nice - at least some snapshot tests to make sure the table renders as expected when the mock ApiService returns either an empty or non-empty result.

Still failing prettier checks ^

CI doesn't seem to like toBeCalledWith, it's passing locally for me and the usage is consistent with other uses of it elsewhere so I'm not entirely sure what's wrong

Could you reorganize the kebab menu for the Thread Dump items? I think the established pattern of "<other actions>, separator, delete" has been working well.

Also, when downloading a thread dump file, it currently just gets saved with the (UU)ID as the filename. I see that you have some logic in Api.service's downloadThreadDump that tries to set the filename like {target.alias}_{thread_dump.id}.thread_dump, but it seems not to work for me. You might try setting the Content-Disposition response header on the backend to get the browser to behave here.

Also, when downloading a thread dump file, it currently just gets saved with the (UU)ID as the filename. I see that you have some logic in Api.service's downloadThreadDump that tries to set the filename like {target.alias}_{thread_dump.id}.thread_dump, but it seems not to work for me. You might try setting the Content-Disposition response header on the backend to get the browser to behave here.

The content-disposition header is already set in the backend, it follows the same structure as the archived recordings download.

Looking into this further the filename is set correctly in the frontend, anchor.download gets set to it, however looking at the request that gets sent to the download endpoint and it's headers, the filename doesn't seem to be specified anywhere.

The query parameter that would set the filename is thus null when it makes it to the backend:

cryostat-1 | 2025-08-01 17:12:59,901 WARN [io.cry.dia.Diagnostics] (executor-thread-8) Handling download Request for key: (IX6TpNMZWQSweVAWEtKTrm_j0OtjGZhC_EoJv-d-o6Y=,5e42ed2f-7ca3-4f33-b3ee-60348ef45060)
cryostat-1 | 2025-08-01 17:12:59,901 WARN [io.cry.dia.Diagnostics] (executor-thread-8) Handling download Request for query: null

So it defaults to using the thread dump id as the filename.

@andrewazores any idea what's causing the above? ^

Looking into this further the filename is set correctly in the frontend, anchor.download gets set to it, however looking at the request that gets sent to the download endpoint and it's headers, the filename doesn't seem to be specified anywhere.

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/a#download

The backend sets the Content-Disposition header based on the S3 filename that it knows about, which is just the UUID. The browser uses this to set the downloaded filename.

I guess that the frontend Api.service downloadFile function should set not only the anchor.download attribute, but also anchor.filename as described by that document - but the backend also sends Content-Disposition with a filename attribute, so the backend (at least in this case) will also need to correctly set the desired filename.

Download filename is now set with cryostatio/cryostat@19b5025

If I open my browser's devtools and watch the network traffic when clicking on the Dashboard card item to trigger a thread dump, I see 1 request to perform the dump and then 3 identical requests in rapid succession to query available dumps (GET https://localhost:8443/api/beta/diagnostics/targets/2/threaddump). The response to the first query does not contain the new dump, and the second two responses do. It seems like only the final query should actually be sent.

Also, if I click the "Invoke Garbage Collection" button on the card instead, then there are also two identical threaddump GET queries sent.

I suspect something is not quite right with some React hooks on the Diagnostics dashboard card, causing it to re-render and re-query state too often.